home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Technotools
/
Technotools (Chestnut CD-ROM)(1993).ISO
/
lantools
/
an106a
/
an106-1
Wrap
Text File
|
1991-05-29
|
38KB
|
903 lines
Measuring Performance in the Extended Print Service Environment
Rich Lee
Senior Consultant
Systems Engineering Division
Abstract:
NetWare print services can be configured for both simple and complex LAN
printing environments. After reviewing several concerns from the low#end
environment, this AppNote focuses on complex printing environments where many
users send jobs to a single print queue. It discusses the issues involved in
high#end printing environments and presents the results of some print service
performance tests in these environments. LAN designers and managers will find
several new techniques for predicting printing performance across the LAN.
Disclaimer
Novell, Inc. makes no representations or warranties with respect to the
contents or use of these Application Notes (AppNotes) or of any of the
third#party products discussed in the AppNotes. Novell reserves the right to
revise these AppNotes and to make changes in their content at any time,
without obligation to notify any person or entity of such revisions or
changes. These AppNotes do not constitute an endorsement of the third#party
product or products that were tested. Configuration(s) tested or described
may or may not be the only available solution. Any test is not a
determination of product quality or correctness, nor does it ensure
compliance with any federal, state or local requirements. Novell does not
warranty products except as stated in applicable Novell product warranties or
license agreements.
Copyright { 1991 by Novell, Inc., Provo, Utah. All rights reserved.
As a means of promoting NetWare AppNotes, Novell grants you without charge
the right to reproduce, distribute and use copies of the AppNotes, provided
you do not receive any payment, commercial benefit or other consideration for
the reproduction or distribution, or change any copyright notices appearing
on or in the document.
Contents
Introduction 5
What Are Extended Print Services? 5
Why Study Extended Print Services? 5
Review of the Low#End Printing Environment 6
The Low#End Printing Model 6
Measuring Time Required to Print 7
Production Rates for Low#End Printing 8
The Effect of Network Awareness 9
The High-End Printing Environment 9
The High#End Printing Model 9
Number of Users per Printer 10
More Than One Job in the Queue 10
Measuring Print Time with Multiple Print Jobs 11
Defining the Dependent Variables 12
Isolating Application Adding Time 13
Extended Print Service Performance Tests 14
Basic Hardware Configuration 14
What We Measured and Why 14
Parameters for Calculation 15
Start Time 15
Dwell Time 15
Adding Time 16
Activation Time 16
Throughput Time 16
Clear Time 17
Print Time 17
Observations and Test Conclusions 17
Implementation Considerations 19
Calculating Average Queue Utilization 19
Probability Modeling 20
Appendix A: Test Results for Extended Print Services 22
Appendix B: High#End Test Configurations 23
Introduction
This Application Note is a follow#up to the information in the #NetWare Print
Service Performance" AppNote published in April 1991. Whereas that AppNote
dealt with measuring print service performance in the low#end printing
environment, this AppNote looks at the issues connected with measuring
performance in the high#end or #extended" printing environment. It reviews
the basic concepts of the low#end printing model, then discusses the
variables that must be considered in the high#end printing model. After
explaining the test methodology for extended print services, it presents some
formulas that can be used in calculating average queue utilization and
probability modeling.
What Are Extended Print Services?
For our purposes, we will define the ground of extended print services as
follows:
Any situation in which there is more than one job in the print queue
at a time is an extended print service##or, more accurately, extends the
print service.
Basic to the understanding of extended print services is that there is no
additional supporting software with which you extend your print services.
Rather, the way you implement applications and hardware configurations
extends your need for print services beyond the low#end printing environment
of one job in one queue.
In the extended printing environment, the print service and queue management
functions do not become active and then go inactive with each print job.
There are jobs to process beyond the current one. These other jobs in the
queue extend (by time and job) print service activity; hence, #extended"
print services.
Why Study Extended Print Services?
Even in low#end printing there can be periods of high usage which look, for
the short term, very much like high#end. There are studies which indicate
that even the most innocuous low#end environment may become a veritable
torrent of printing activity, due more to human nature than to technical
variables. (We'll look more closely at this phenomenon in a future AppNote.)
Because of the potential intersection of low#end and high#end printing, even
the low#end environment may present the LAN supervisor with difficulties
normally encountered in high#end printing scenarios. What's more, users often
get downright hostile when network printing slows down. For these reasons,
the LAN supervisor should plan printing resources with the worst case in
mind, or at least think through the ramifications for the maximum expected
load. This can be hard to do, and may require gathering information from
several sources. Hopefully the information in this AppNote will help.
Review of the Low#End Printing Environment
The #NetWare Print Service Performance" AppNote was concerned with measuring
printing rate (in bytes per second) and production performance (in PPM and
GPPM) in the low#end environment. It also dealt with determining what aspects
of printing were production bottlenecks and calculating the throughput of the
document to the printer. We measured delivery performance using Word Perfect
5.0 as our test application. We also briefly mentioned the difference between
NetWare aware and unaware printing, and working around the CAPTURE command.
In those studies, we came to several conclusions. Primarily, we saw that
transmission rate is not a very useful measurement of printing performance.
Rates can be misleading, especially with graphics output. Production
performance at the printer is a far better measure of printing throughput.
There were some other items of interest. Printing rates overall were slow,
mainly because the applications just did not format and send the data
rapidly. Printing at the printer was also slow, especially through serial
ports. If all printing were done at the typical low#end rate of 2,242 bytes
per second, high#end printing would suffer.
The Low#End Printing Model
All of this went to further our understanding of the low#end printing model,
where print jobs must be added to a queue before the print redirection
process can be attended to by the network print services.
shows how we measured total print time in the low#end scenario (one job in
the queue).
: Low#end Printing Scenario
Our definition of the low#end environment does not necessarily imply that you
have a small number of users. It does imply that there is little network
printing being done (because there is only one job in the queue at any given
time.) However, the actual amount of setup and maintenance work is
disproportionate to the amount of printing that takes place. A LAN supervisor
defining print queues, printer definitions, and printer configurations
cannot afford to maintain a high#end network using low#end options. Whereas
a LAN supervisor in the low#end might define one queue for users and provide
PRINTCON and PRINTDEF definitions for their individual needs, in the high#end
a print queue might need to be designed for a particular type of printing
(for instance, letterhead) and other queues might be set for other printer
specific functions.
Measuring Time Required to Print
The essence of low#end printing is calculating how long it takes to print one
job. This section gives a quick review of how this can be done.
Production Rates for Low#End Printing
lists typical production rates as determined in our low#end printing tests.
These rates can be used in determining the time an application takes to
produce a printed document.
: Production Rates for Low#End Printing
For example, if you want to know how long it would take to print a Graphics
Only document in WordPerfect you'd need to know the production rate first.
Referring to , you can use the following formula for calculating the
approximate time to produce a completed document for a specific printer type:
DOCUMENT SIZE (bytes)
PRINT TIME (sec) = -----------------------------
(2-1)
PRODUCTION RATE (bytes/sec)
The variables in this formula are defined as follows:
Document Size = Transmittable size of the document (in bytes)
by
document type
Note that this is not the same as the size of the document as it is stored on
disk. When you send a document to be printed, the size increases because of
the additional information that is set to the printer. To see the difference,
use CAPTURE CR = FileName TI=nn and observe the size of the resultant file.
Production Rate = Bytes per second to transmit the document to
the printer (from the table)
Of course, you also need to know the printer port type (parallel or serial)
and the document type (G/O, STR, T/G, or T/O) to do the calculation. The
table only shows the rates for G/O documents sent to an HP PCL#5 printer
through a parallel port. See the April AppNote for more complete tables.
Remember also that the printable document size is computed from the printer
output when the document is sent to the printer.
The Effect of Network Awareness
The rates shown above are for applications that have network#aware printing
capabilities. Using the CAPTURE command to redirect local printing to the
network decreases the rate and increases the time to print the document
considerably. If you want to use an application that does not use
network#aware printing, the increase in print time may or may not be a
problem. However, you might contact the program's manufacturer and let them
know how beneficial the addition of network#aware capabilities would be.
This type of calculation for print time is useful only to someone in the
low#end printing environment. Once you move into the high#end environment
(with more than one job in the queue), the methods for calculating how
quickly a job can be produced change drastically.
The High-End Printing Environment
Having reviewed the low#end printing environment, we are ready to pursue the
next step of the printing series, which is to further divide the matrix to
cover more complex situations.
The High#End Printing Model
The contrasts between the low#end and high#end of printing are mainly found
in:
w the relative organization of the print service structures (which
print services are selected)
w the reasons behind creating additional print queues (the problem you
are trying to solve)
w the quantity of print jobs (how much paper is used)
w the frequency of print queue utilization (how many jobs are in the
queue at a time)
Admittedly, there are more ways of combining the above factors than any one
article can deal with. We'll focus on print job quantity and the methodology
used to redirect and complete those jobs. In the low#end there is
occasionally quantity, but rarely the increased use of options to handle
additional workload. In the high#end there is often a large quantity of
print jobs, along with numerous options for handling the workload.
In the high#end model, you have more queues, more users, and usually a longer
period of time before all current jobs are done. To do any type of prediction
on how long it will take to get a job printed, you must consider the
following factors.
Number of Users per Printer
Determining how many people are using each printer is trickier than it seems.
Often a printer has more than one queue sending work. You may have to
account for users from different parts of the network before you can study
the actual printer activity. The following is a rough formula that might help
you:
N = NP1Q1 + NP1Q2 + ... +NP1(Sn/Qn)
(2-2)
where
N = Number of user for Printer #1
NP1Q1 = Number of users sending jobs to Printer #1 via Queue #1
NP1Q2 = Number of users sending jobs to Printer #1 via Queue #2
NP1(Sn/Qn) = Number of users sending jobs to Printer #1 via Queue n on Server
n
More Than One Job in the Queue
The main difference between low#end and high#end printing is that in the
high#end environment a second print job is already in the queue ready to be
activated. In this case, the relationship in formula 2-1 relating printing
time to the length of the document cannot be used. The total time to produce
the document is now reliant to some degree upon the time in which other
documents are finished at the printer.
shows the events that must be measured to determine total time to print in
the high#end environment.
: High#end Printing Scenario
The times labled T0 through T7 will be defined later in this AppNote.
In , the three print jobs arrive in the queue at about the same time. shows
other possibilities for how jobs can arrive in the queue.
: Three Ways Multiple Jobs Can Arrive in the Queue
Scenario #1 in resembles the low#end model. It is when print jobs start to
overlap in the queue that we move into the high#end and measuring time to
print becomes more difficult.
Measuring Print Time with Multiple Print Jobs
Now that we have covered some of the differences between low#end and high#end
printing environments, we can examine how to measure performance in the
high#end environment.
In the low#end environment, we measured performance as the total time to
print divided into the total pages printed:
NUMBER OF PAGES
PPM (pages/min) = --------------------
(2-3)
TIME TO PRINT
The time to print was measured from the job initiation (to) to the printing
completion time (tn) when the last page came out of the printer.
T (time to print) = tn # to
(2-4)
In the high#end, the time to print a document is influenced by the number of
jobs ahead of the one you want to print:
Total Time = T(job #1) + T(job #N) ... + T(your job)
(2-5)
This creates a difficulty for the designer or supervisor (not to mention the
user) in that you must be able to predict the number of print jobs to
determine the amount of hardware that must be allocated, to say nothing of
the manpower required for preparation and implementation. It changes the
environment to one where probabilities describe the time to print a document.
Defining the Dependent Variables
In working with extended print service performance, we need to define more
terms. For our performance testing, we divided the observable print service
functions into distinctly quantifiable parameters.
Some of the parameters received names based upon a necessary measure; others
were named from calculated test results. For instance, the time for a print
job to be added to a queue was seen as distinctly different from the time to
deliver it to the printer. This parameter was called the Queue Adding time.
Each of the other distinct functions inherent to the print service function
were looked at and named in a similar fashion. lists the dependent variables
we identified
: Dependent Variables for Measuring Extended Print Service Performance
These variables are shown in . TESTDOC would be the job sent by User 1, and
FINALDOC would be the job sent by User 2. We'll talk more about these
variables later.
Isolating Application Adding Time
Defining these measurable quantities was not enough. We also had to determine
if they had a function, what measuring them actually described in the system,
and what print service was actually responsible for the performance measured.
For instance, T2 (the Adding time) is the difference between t2 (the measured
time) and to (the time at initiation).
T2 = t2(time at Ready flag) # t0(time at start)
(2-6)
The resultant T2 is the absolute time from the start. The Adding time was the
amount of time the application took to add the document to the queue and for
the #Ready" flag to be produced in PCONSOLE. Observably, Adding times were
longer for applications adding print jobs than for NPRINT to add to the
queue. This made sense, since NPRINT sends already formatted
printer#compatible output.
We saw Adding time as a significant number for two other reasons. One, the
first job in the queue would put its Adding time on in front of any other
subsequently added job (that is, another job that is added before the first
one clears or is sufficiently long to be adding when the first one is clear.
Although different in detail, the instance looks much the same to the waiting
users.) Two, different applications have different Adding times, but the
Adding time becomes less significant as the job length increases.
From our low#end study, we knew that the document type had a direct effect on
the printer performance. In the area of high#end printing, we recognized that
the document type would continue to have a marked effect on the queue Adding
time and on the printer response time. We also knew that the printing port
(parallel or serial) had some of the greatest effect upon printing
performance. The questions we had were:
w Will the limitations of the printing port dictate the amount of queue
loading and (subsequently) the printing performance at the printer?
w Will the printing rate from the queue to the printer be significantly
high that jobs from the queue will drain out instead of build up?
w Will the institution of alternate printers and services be necessary
to maintain printing performance? These questions will have to be answered
later.
What we're ultimately aiming for is a formula or table which would be useful
in predicting the time to receive print jobs in the high#end environment. At
least this would be something to justify the purchase of another printer, and
help in the future matter of how to maintain all of this as a LAN supervisor.
Extended Print Service Performance Tests
In designing our extended printing performance tests, we used two major
operating systems: NetWare v2.2 and v3.11. The testing configurations were
similar to the configurations tested in the low# end study, with the
following differences:
w the ports tested (only parallel, no serial)
w the type of printers used (HPIII and HPIIIsi with its own network
interface card)
w the number of queues (some tests utilized two loaded queues)
Basic Hardware Configuration
shows our basic hardware configuration. As usual, all of the testing was
done on thin Ethernet cable with NE2000 cards. Most of the testing revolved
around manipulating the parameters and workloads in one configuration.
: Basic Test Configuration
What We Measured and Why
In the testing regimen, our interest centered around times of delivery to
anywhere and everywhere the print job was tracked before it was finished at
the printer. Our interest in where the job went and how long it was there led
us through the parts of NetWare printing we could measure and gave us some
insight into what processes were taking how long in the printing environment.
As mentioned before, we had decided to break the printing process into the
major component parts that we could discriminate. From those we would try to
discern what factors were pertinent in measuring the print services and which
were extraneous.
From , we were able to break print services into the following major
components: Start time, Dwell time, Adding time, Activation time, Throughput
time, Clear time, and Print time.
Parameters for Calculation
This section discusses derived values. The derived values are the result of
subtracting the tn values discussed in the previous section. The resulting
values have been assigned capital letters. The time formulas, or #T"
formulas, provide us with several insights and a few questions which we do
not have answers for yet.
Start Time
The first parameter is Start Time. In and of itself, it only marks the
beginning of the test. However, it has become the basis by which we measure
the absolute time of events on the printing side of the network.
To = START TIME
(2-7)
Dwell Time
The next item we will call Dwell time, until we come up with a more
descriptive name. Dwell time is the interval between the start of a print job
(user print initiation) and the time it actually starts being added to the
queue. Note that we mean the time the Adding flag is set, not the time it
actually appears in PCONSOLE. Ideally, this is what we would have liked to
measure. But the lack of sophisticated#enough tools prevented it. What we
measured was the time until the Adding flag appeared.
T1 = DWELL TIME = t1 # t0
(2-8)
The value of Dwell time is that it tells us the amount of time between the
user initiating printing to the network and the time for the network to
initiate the response that says #OK, adding job XYZ." That also includes
formatting time for the application.
So what value is there in measuring the Dwell variable? Probably more than
just how long you have to wait for the PCONSOLE #Adding" message to come on.
Actually, it tells you a lot about the application's ability to print
immediately or wait for other processes. On a busy network (85 percent
utilization), Dwell time does not appear to take any longer than on a 30
percent utilized network.
That is one of the reasons we used NPRINT for our testing. It significantly
reduced the wait for T1. (For now, Dwell time is a measurable number of
questionable significance.)
Adding Time
Adding time is calculated in the same way as the Dwell time:
T2 = ADDING TIME = t2 # t0
(2-9)
This is the time it takes to get the #Ready" message in PCONSOLE, and
represents the amount of time for the application to send the formatted data
to the queue.
Activation Time
The Activation time is how long it takes to get the #Active" flag from
PCONSOLE. At this point, everything is in the print queue and the print
service has gone active to the printer.
T3 = ACTIVATION TIME = t3 # t0
(2-10)
Throughput Time
One of the measurements taken which has not been evaluated thoroughly is the
THRU time, the time for the first sheet to be printed.
T4 = THRU TIME = t4 # t0
(2-11)
This is probably a misnomer and the selection of using the first sheet from
the printer is probably a mistake. That will have to wait for another set of
tests to verify. What it should have measured (and at this point probably
does not) is the effect on the print service of utilizing PRINTCON and
PRINTDEF. It might provide some insight into the performance activity
relation with and without those utilities. For now, the data was sampled
without PRINTCON or PRINTDEF.
Clear Time
Next is the #Clear" time, which we define as the disappearance of the
#Active" message from PCONSOLE. Interestingly enough, in all cases this
corresponded to the NEXT JOB time that we were trying to obtain as a
different measurement. The #Active" message appeared for the next print job
in the queue just as the last job cleared.
T5 = CLEAR TIME = t5 # t0
(2-12)
Print Time
The last measured time was when the final page of the print job came out of
the printer. This Print time, as we dubbed it, was the time for the job to
complete at the printer. T6 would be the time to use for calculating printing
performance.
T6 = PRINT TIME = t6 # t0
(2-13)
Observations and Test Conclusions
The results of our extended print services tests are given in Appendix A. We
had the opportunity to make several observations during our testing regimen.
As observations, they have to be qualified as such. They are not necessarily
tested results, and may prove completely erroneous.
One of the most interesting things we observed during the printing tests was
the server utilization. During the server loading tests for the HPIII using
the parallel port, the server utilization normally went from 50 percent
(loaded) to 85 percent and then varied from 67 percent to 92 percent for the
remainder of the printing process. When the HPIIIsi was tested under the same
conditions, the server utilization went to 85 percent momentarily, dropped
back to 50 percent (the load factor) for most of the print job, increased
briefly to 70 percent, then returned to 50 percent.
We were looking for some simple time measurements that indicated print job
transmission rates across the network. We found just those, but with an
interesting twist. When the parallel port was being tested, we could see the
transmission rate of the parallel port was definitely affecting the
production rate so that nothing was going to the printer faster than 1,799
bps. With the HPIIIsi, the transmission rate to the printer was higher.
The results in show the comparison between NetWare v2.2 and v3.11 for
parallel port HPIIIsi printing with regard to the t5 # t3 time. This brought
up some question as to what effect replicating the experiment with a Graphics
Only document would have, so we tested it as well.
: Comparison of Rates with VAP and NLM
Interestingly, the results for the HPIIIsi indicate that with the influence
of the parallel port removed and the printer changed (between the HPIII and
the HPIIIsi), the transmission rate from the queue to the paper was no longer
a major limiting factor in print job production. A Graphics Only document
moves through the queue almost as fast as a Text/Graphics document does.
Implementation Considerations
One of the major concerns in implementing extended print services is user
convenience. The whole point of optimizing print services is to give the user
as optimal a consideration as possible, while maintaining (if not optimizing)
the ability to manage the activity and the network. Users bear the brunt of
the work activity (#load"); the computer could care less. Over the years,
users have increased their productivity, and now with the microcomputer being
well established there is no reason to expect that productivity to decline.
In fact, faster CPUs, better application software, and faster peripherals all
precede an even greater surge in productivity. As we view users, we find that
almost universally they become more proficient at whatever tasks they have.
Printing is no exception. With all these increasingly productive software
users printing, LAN services will have to improve. The areas of design,
implementation, and supervision will all need sharper, faster tools.
In the meantime, here are a few formulas which may not alter the shape of
your LAN, but may provide just enough ammunition in the next planning meeting
to get you the additional items you need.
Calculating Average Queue Utilization
One calculation that may prove very useful to the LAN supervisor is a simple
but effective average of time the queue is utilized.
T(App.Avg.(full)) + (N#1) T(Avg.
Active)
Avg. Printing Time = ---------------------------
(2-14)
N
Note that (N#1), the number of people printing minus one, is not a subscript,
but a multiplier.
Here T(App.Avg.(full)) is equal to the average measured full time for an
application to print through to the printer (assuming no queue priorities
have been set). It must take into account all the types of print jobs that
different types of users may send to that queue. If you want to determine
this number, get a sampling of the documents used by a queue's workgroup for
that queue specifically and print them out, one at a time. Then take the
average.
The result in formula 2-14 is the average time to complete printing for all
of the users in a queue. You can expend a lot of work in determining this
number, especially if individuals in the queue workgroup or queue#group are
highly heterogeneous in their printing. But the result, especially for peak
period printing, is extremely useful. It can tell you approximately how long
the last person will wait for a print job in peak periods.
It is up to the LAN supervisor or print manager to get with the users and
work out a solution if this time is too long. How long is too long is
something you will have to work out within your own workgroups and budget
constraints. However, it does present the necessity for exploring some of the
alternatives in print service design. Options you may wish to explore
include:
w multiple queues
w multiple (existing or new) printers to a queue with user notification
w high speed printers
w consolidating several queues
w changing the physical design of the printing workgroups
Probability Modeling
The next activity that may be of interest is calculating the probability of
getting your own job through in a period of time. Using a typical example
such as ten people, each with five print jobs to do by noon, usually gives
the wrong result. This oversimplification does not take into consideration
that the five print jobs are six#page contracts, that they are in revision
two times, that they are printed for the individual with each revision, and
that they all have to go out by noon. What this means is ten people will be
printing those jobs twice between 11:00 a.m. and 11:45 a.m. That's 100 print
jobs (fancifully the short ones are one page long) all to be printed in 45
minutes.
Now suppose the print jobs are real estate letters and each one of them
contains a graphic. It's going to take the ten users 1 second each to begin
the printing cycle; unfortunately only one user can be first. The other nine
will get their jobs in after the lucky first user. Several people are going
to have to wait; the only question is who and for how long.
Regarding the #who" question, you can always set the queue priority for
several queues talking to one printer. This lets you get the chief
executive's print job scheduled as number 2 with multiple queues to one
printer, even when the job is sent as number 6.
Having several queues talking to one printer gives our average time formula a
bit of a twist, because the number N in the formula now has to take into
consideration all of the queue#groups that talk to one printer.
N = n (queue group #1) + ... + n (queue group #N)
(2-15)
With this value for N, it should not take longer for the last job to be
printed than the average print time multiplied by the number of users.
T(App.Avg.(full)) + (N#1) T(Avg. Active)
Avg. Printing Time = ----------------------------
(2-16) N
For peak period printing with printer contention from other queue#groups, the
probability model for the priority 2 queue with a priority 1 queue attached
begins to look like:
(T(App.Avg.(full)) + T(Avg. Active Queue1)) x (N-2) +
T(Avg. Active Queue2)
Avg. Printing Time = ---------------------------------------------------
(2-17)
NToT
For periods with no contention, it looks like:
Avg. Printing Time = T(App. Avg. (full) Queue2)
(2-18)
Normally it should not take longer than the above average time for the
non#priority job to get through the printer.
Of course, you can take this type of modeling beyond its useful boundaries,
but figuring your average print time does provide the groundwork for a
discussion on when new printers may need to be added and what queues will
have priority over the others.
Appendix A: Test Results for Extended Print Services
The following table lists the times recorded during the extended print
service tests. The absolute times (ABS) indicate cumulative time from the
initiation of the print job. The delta times represent the difference between
each discrete measurement. For an explanation of the numbers in the #Test
Config" column, see Appendix B.
TEST ABS... DELTA. ABS... DELTA. ABS... DELTA. ABS... DELTA. ABS...
DELTA. ABS... DELTA.
CONFIG T1 T1 T2 T2 T3 T3 T4 T4 T5 T5
T6 T6
(Sec.) (Sec.) (Sec.) (Sec.) (Sec.) (Sec.) (Sec.) (Sec.) (Sec.)
(Sec.) (Sec.) (Sec.)
______ ______ ______ ______ ______ ______ ______ ______ ______
______ ______ ______
19 3 3 8 5 12 4 35 23 53
41 70 17
19 5 5 10 5 12 2 30 18 50
38 59 9
19 2 2 7 5 22 15 43 21 62
40 71 9
20 3 3 8 5 9 1 28 19 48
39 58 10
20 7 7 12 5 17 5 41 24 56
39 69 13
20 4 4 8 4 18 10 41 23 59
41 70 11
21 5 5 9 4 11 2 34 23 50
39 63 13
21 5 5 6 1 11 5 34 23 50
39 62 12
21 4 4 6 2 10 4 25 15 44
34 55 11
22 3 3 8 5 18 10 64 46 64
46 77 13
22 5 5 10 5 15 5 39 24 55
40 65 10
22 4 4 5 1 19 14 42 23 59
40 70 11
23 6 6 8 2 21 13 83 62 216
195 235 19
23 5 5 7 2 17 10 101 84 197
180 217 20
23 3 3 3 0 14 11 76 62 209
195 229 20
26 4 4 9 5 10 1 99 89 214
204 215 1
26 3 3 9 6 14 5 60 46 194
180 213 19
26 3 3 7 4 18 11 75 57 214
196 231 17
27 3 3 8 5 18 10 69 51 168
150 187 19
27 4 4 4 0 37 33 75 38 187
150 204 17
27 4 4 4 0 15 11 72 57 178
163 201 23
31 2 2 10 8 12 2 31 19 41
29 54 13
31 5 5 5 0 6 1 28 22 40
34 53 13
31 1 1 8 7 8 0 28 20 41
33 51 10
34 2 2 7 5 17 10 38 21 47
30 61 14
35 2 2 3 1 12 9 32 20 34
22 46 12
35 2 2 7 5 17 10 32 15 33
16 47 14
35 5 5 6 1 10 4 25 15 25
15 38 13
Appendix B: High#End Test Configurations
This appendix details the hardware and software configurations (numbered 19
through 35) used for the extended print service performance tests. These are
the numbers indicated in the #Test Config" column in Appendix A.
Printer
DOCUMENT
N0. Type Config OS QUEUES LOAD PSERVER VERSION Size Type
METHOD
19 HPIIIsi F/S 2.2 1 U VAP V1.21
270451 T/G NPRINT
20 HPIIIsi F/S 2.2 2 U VAP V1.21 270451 T/G
NPRINT
21 HPIIIsi F/S 2.2 2 L VAP V1.21 270451 T/G
NPRINT
22 HPIIIsi F/S 2.2 1 L VAP V1.21 270451 T/G
NPRINT
23 HPIII F/S 2.2 1 U VAP V1.21 270451 T/G
NPRINT
24 HPIII F/S 2.2 2 U VAP V1.21 270451 T/G
NPRINT
25 HPIII F/S 2.2 2 L VAP V1.21 270451 T/G
NPRINT
26 HPIII F/S 2.2 1 L VAP V1.21 270451 T/G
NPRINT
27 HPIII F/S 3.1 1 U NLM V1.21
270451 T/G NPRINT
28 HPIII F/S 3.1 1 L NLM V1.21 270451 T/G
NPRINT
29 HPIII F/S 3.1 2 L NLM V1.21 270451 T/G
NPRINT
30 HPIII F/S 3.1 2 U NLM V1.21 270451 T/G
NPRINT
31 HPIIIsi F/S 3.1 1 U NLM V1.21
270451 T/G NPRINT
32 HPIIIsi F/S 3.1 1 L NLM V1.21
270451 T/G NPRINT
33 HPIIIsi F/S 3.1 2 L NLM V1.21
270451 T/G NPRINT
34 HPIIIsi F/S 3.1 2 U NLM V1.21
270451 T/G NPRINT
35 HPIIIsi F/S 3.1 1 U NLM 1.21 150807 G/0
NPRINT
Editor's Note: The author accepts written feedback at FAX (801) 429#5511.